Cloud database vendor lock-in is one of the most expensive surprises in enterprise infrastructure — not because the dependency is hidden, but because most teams never quantify it before committing to a platform. Each distinct type – engine lock-in, feature lock-in, and operational lock-in – accumulates differently, costs a different amount to exit, and requires a different conversation before you migrate.

This article breaks down exactly what each type means, which cloud providers create the deepest dependencies, and introduces a four-question framework for measuring your own lock-in — before a pricing change, service deprecation or organizational shift forces the issue.

Every time you move a database workload to a managed cloud service, you (and your team) are accepting some form of vendor dependency (‘lock-in’). However, what normally isn’t accepted is exactly what you are committed to, how deep it runs, and what it would actually cost to undo. It’s a conversation so many teams never have before committing to a cloud migration – and it’s an important, potentially costly, one to miss.

Why does this happen – and what are the consequences?

That conversation gets deferred because the managed service is genuinely useful, so there’s pressure to migrate to it. Plus, this vendor lock-in problem you’re hearing about seems so insignificant – maybe even hypothetical – next to the operational problem you and the team are currently struggling through.

However, it very much stops feeling hypothetical when your provider raises prices, changes a service behavior your application depended on or, worse still, the needs of your organization change enough that the cloud service is no longer required.

This article makes the lock-in conversation specific, explaining the three distinct types of cloud database dependency. Understanding which type you are accumulating, and how much of it, is the kind of clarity you need before making a big migration decision – not after, when it’s too late.

What are the 3 types of cloud database lock-in?

Engine lock-in, feature lock-in, and operational lock-in. These are the three distinct types of cloud database lock-in, but what do they each mean? What are the differences between them? Let’s find out.

Engine lock-in (the least dangerous type)

Engine lock-in means dependency on a specific database product, not on a specific vendor’s infrastructure. The migration is operationally painful – it involves downtime planning, data transfer, connection string updates, and validation. However, it’s technically straightforward, because the engine runs the same code wherever it runs. 

It’s also, in practice, often the least expensive to exit. If you’re running PostgreSQL on Amazon RDS, the database engine is standard, community-maintained PostgreSQL. Your schemas, stored procedures, queries, and application connection strings work against any PostgreSQL instance, anywhere.

So, if you decide to migrate to Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL, or a self-hosted instance, the technical barriers are low. 

The reason this matters less than it appears is that organizations rarely remain at engine-level dependency once they begin using a managed service. The managed service features that make it worth choosing over self-hosted are almost always provider-specific.

Feature lock-in (where the actual costs accumulate) 

Feature lock-in occurs when you build application behavior that depends on capabilities specific to one provider’s implementation of a database engine. The data is portable, but the behavior is not. 

Amazon Aurora is the clearest example. Aurora presents itself as MySQL-compatible and PostgreSQL-compatible, and at the protocol level, that is largely accurate. But Aurora’s underlying storage layer is not MySQL or PostgreSQL storage – it’s a distributed log-based storage system engineered by AWS that exists nowhere outside of AWS.

This architecture delivers genuine performance advantages: up to five times the throughput of standard MySQL on equivalent hardware, up to 15 read replicas (compared to five for standard RDS), and lower replication lag under write-heavy workloads. 

Those advantages come from Aurora-specific design. For example, Aurora’s exclusive backtrack capability, which lets you rewind the database to a previous point without restoring from a backup. Then there’s Aurora Global Database’s cross-region replication, which has different semantics from standard PostgreSQL streaming replication.

And finally, Aurora Serverless v2’s autoscaling behavior, which responds to traffic changes in fine-grained increments that have no equivalent on other platforms. 

The point is simple: if you build operational runbooks, application logic, or disaster recovery procedures that depend on any of these behaviors, you have feature lock-in. Migrating your data from Aurora to standard PostgreSQL is technically straightforward.

Replicating Aurora’s performance characteristics and operational behaviors on a different platform, however…that’s a different engineering project entirely,  and one that often takes longer than the data migration itself. 

Operational lock-in (the most underestimated type) 

Operational lock-in is the accumulation of integrations, monitoring configurations, automation scripts, IAM policies, VPC configurations, credential management approaches, alerting setups, and institutional knowledge that builds up around a specific managed service over time. It’s both the least discussed type and the most expensive to exit. 

Let’s take, for example, a database that has been running on Amazon RDS for three years. Typically, it’ll have CloudWatch dashboards tuned to its specific metrics, AWS IAM roles configured for access control, automated backup jobs defined in RDS parameter groups, performance insights reports that the team references daily, and staff who know how to interpret RDS console outputs.

None of that is the database itself. Instead, it’s all the operational context around the database – and crucially, it doesn’t transfer to another platform. When organizations underestimate migration costs, this is nearly always where the discrepancy comes from.

There’s also the time cost to consider. The data migration may have only taken two weeks, but the operational infrastructure rebuild takes three months. Retraining the team to work with a different management interface and toolset? That’s another two months. These costs are practically invisible until the migration is actually underway, so they rarely surface in initial vendor comparison exercises.

Cloud vendors and lock-in: a guide

Let’s now look at some cloud vendors and how each handles lock-in. Here, we’re focusing on Amazon Aurora, Azure SQL Managed Instance, and Google Cloud Spanner.

Amazon Aurora 

Amazon Aurora genuinely delivers on its performance claims before it creates its dependencies. AWS announced Aurora DSQL at re:Invent 2024, positioning it as a serverless distributed SQL database with 99.999% multi-region availability and active-active architecture.

By Q1 2026, Aurora DSQL had reached general availability across four AWS regions, in direct competition with Google Cloud Spanner and CockroachDB Dedicated. 

The technical claims are substantiated. Aurora DSQL uses optimistic concurrency control rather than the traditional pessimistic locking approach, which eliminates lock contention in distributed write scenarios and reduces cross-region write latency compared to traditional multi-version concurrency control (MVCC) implementations. These are major benefits for organizations running globally (geographically) distributed applications with high write throughput.

The lock-in comes from what you give up to get these capabilities. Aurora DSQL’s documentation is explicit: the service doesn’t support explicit database locks (because it uses optimistic concurrency control), foreign keys, temporary tables, or certain PostgreSQL extensions.

Additionally, if your application contains SELECT FOR UPDATE statements or advisory locks, it needs to be refactored before using Aurora DSQL. Every application pattern you build to work around these constraints is application logic specific to Aurora DSQL’s behavior. 

AWS’s own documentation describes Aurora as creating ‘a different vendor lock-in by providing unmatched ROI.’ That’s a remarkably candid statement, but it’s true: the return on investment is real. In turn, so is the lock-in, which only deepens with every Aurora-specific feature you adopt.

Azure SQL Managed Instance

Azure SQL Managed Instance (MI) occupies a different position in the lock-in landscape, marketed on proprietary performance features rather than just compatibility. 

Microsoft’s documentation positions it as being nearly 100% compatible with on-premises SQL Server, designed specifically for lift-and-shift migration of existing workloads. That compatibility is real and meaningful for organizations migrating complex SQL Server environments to the cloud. 

The lock-in story here is ecosystem lock-in rather than feature lock-in. Instead of offering exotic capabilities that can’t be replicated elsewhere, Managed Instance integrates tightly with Microsoft Entra ID for authentication, Azure Monitor for observability, Azure Blob Storage for backup destinations, and the Azure networking stack for connectivity. For organizations already invested in the Microsoft ecosystem, this makes it a no-brainer to use MI.

There are also documented gaps between Managed Instance and on-premises SQL Server worth understanding before migration. Microsoft’s T-SQL differences documentation lists specific behaviors around linked servers, which in MI are limited to a small set of Azure targets and SQL Server instances, with no support for external file systems or other relational databases, backup and restore operations, certain replication scenarios, and distributed transactions. These gaps have narrowed with each release but remain relevant for complex on-premises environments. 

For organizations coming from SQL Server, Managed Instance is often the most viable cloud path because the alternatives require more extensive re-platforming. Said organizations just need to remember that choosing Managed Instance means committing to a deepening integration with the Azure services stack that surrounds it.

Google Cloud Spanner 

Google Cloud Spanner is a globally-distributed relational database built on Google’s proprietary TrueTime infrastructure, atomic clocks, and GPS receivers distributed across Google’s data centers. It represents the most complete form of cloud database lock-in in commercial use – and is quite honest about it.

Cloud Spanner provides external consistency across regions – delivering horizontal scaling with strong consistency without the consistency compromises that typically accompany distributed systems. 

The SQL dialect Spanner uses is not standard ANSI SQL. It diverges from PostgreSQL and MySQL on data types, functions, and query semantics in ways that make application code written for Spanner non-portable to other databases without meaningful rewriting.

Furthermore, Spanner doesn’t support foreign keys in the same way traditional RDBMS products do. Its pricing model, based on nodes or processing units, is Spanner-specific, so doesn’t align with other database services. Broadly speaking, organizations using Spanner know and accept this. The distributed consistency properties Spanner delivers aren’t available at the same operational simplicity as any other platform. 

For example, CockroachDB and YugabyteDB offer comparable consistency models but require more operational involvement. Similarily, Aurora DSQL is competitive for certain workloads but is newer, with more constraints. Spanner’s specific – and prominent – technical position is chosen by organizations choose because the alternative is building the distributed consistency infrastructure themselves. 

The organizations that run into problems with Spanner are the ones who adopted it for a workload that didn’t actually require its distributed consistency capabilities. Before realizing this, they’d already built application logic specific to the platform. The result is SQL dialect differences and the absence of standard foreign key behavior – issues that compound over time.

How do you measure cloud lock-in? The four-question framework you should use

Before adopting a cloud database service or auditing one you already rely on, these four questions make the dependency concrete enough to inform a real decision.

1. What does a complete data export look like – and can you run it today? 

For standard PostgreSQL on RDS, you can run pg_dump and restore the output anywhere PostgreSQL runs. For Aurora DSQL with optimistic concurrency control behavior embedded in your application code, the data export is straightforward, but the behavioral compatibility is not. Running through this exercise before you need to do it tells you the actual complexity.

2. How much application code depends on provider-specific behaviors? 

Stored procedures that reference Aurora-specific system variables. Every monitoring integration that reads CloudWatch-specific metrics rather than standard database views. Each authentication flow that uses AWS IAM database authentication rather than standard credentials. These are all examples on lock-in ‘surfaces.’

Why is this important? Well, put simply, listing them all gives you an estimation of migration cost – even if migration isn’t a current priority. You’ll know if the list is too long before it becomes relevant…and costly.

3. How many other services does this database integrate with, and are those integrations portable? 

What’s the significance of a database that feeds an event stream to a cloud-native message queue, triggers cloud-native functions on changes, and is monitored through a cloud-native observability platform? Answer: it has accumulated operational lock-in well beyond the database itself.

Moving the database to a different provider doesn’t move any of that integration infrastructure, either. Understanding the full integration surface is necessary for any realistic migration cost estimate.

4. You need to move in 12 months. How long will it take, and how much will it cost?

You need to be concrete here. Estimate the data migration time, the operational infrastructure rebuild, the integration rework, and the time spent on team retraining. If, once added up, the number is 18 months and many engineers, you have useful information regardless of whether migration is currently on the roadmap. Information that should inform every significant cloud database platform decision. 

In conclusion: navigating cloud database lock-in

The goal of this framework is not to argue against cloud database lock-in categorically. For many organizations, deep integration with a single provider’s services is the right decision.

It might be that Aurora’s performance and operational simplicity are a huge asset to you. Or perhaps it’s Azure SQL Managed Instance’s SQL Server compatibility, removing (expensive) migration friction for your organization. And then there’s Spanner’s global consistency capabilities, which are unique. 

In short, it’s not a mistake to choose a ‘locked-in’ service. It is a mistake, however, to choose one without making the trade-off explicit and understanding what exit actually looks like. Organizations with a full understanding of the depth of their lock-in are in a much better position to negotiate with their provider, plan for scenarios that require changes, and evaluate new options as they emerge.

On the other hand, organizations that discover their lock-in during an emergency simply do not have these options. 

Measure before you build. The cost of that clarity is a few hours of architecture discussion – significantly less hefty than the cost, and consequences, of discovering it during an unplanned re-platforming event.